Amazon WorkSpaces Coreに関する情報まとめ (2022年末版)

Amazon WorkSpaces Coreに関する情報まとめ (2022年末版)

Clock Icon2022.12.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

しばたです。

今年の9月に発表された新サービスであるAmazon WorkSpaces Coreに関してある程度情報が増えてきたので本日時点の状況をまとめてみました。

https://dev.classmethod.jp/articles/aws-announces-amazon-workspaces-core/

リンク集

現時点でわかるAWSやVMwareの参考情報です。
細かい点で違いはあるものの基本的な部分はどの資料でも変わらないため、まずはAWSのBlogだけ見ておくと良いでしょう。

AWS

基本的にはre:Inventとその前に行われたEnd User Computing Innovation Dayの資料になります。

VMware

VMwareの資料ではサービス発表時のBlogの他に1つだけ解説動画を見つけることができました。

おまけ : DevelopersIO

DevelopersIOにあるのは私の記事だけです。

現時点のまとめ

これらの資料からわかる本日時点でのAmazon WorkSpaces Coreについて改めて解説します。

Amazon WorkSpaces Core とは

Amazon WorkSpaces CoreはAmazon WorkSpacesのインフラ基盤をAPIの形で提供するサービスでで公開するサービスで、VMwareなどのサードパーティー他社VDIソフトウェアからAmazon WorkSpacesのインフラを扱える様にするためのものです。
この点はサービス発表時点にもお伝えした通りですが、新たにわかったのは

  • 他社VDIソフトウェアの管理基盤(コントロールプレーン)はそのまま使う
  • 提供する仮想マシン(データプレーン)のみAmazon WorkSpacesで提供する

という形になるということです。
本日時点ではVMware Horizonとの連携だけ公開されていますが、Horizonのコントロールプレーンとなる

  • Unified Access Gateway
  • Connection Server

や、それに付随して必要となる

  • Active Directory環境
  • イベントデータベース

は自前で用意する必要があります。
Amazon WorkSpaces Coreが提供するのはあくまでも仮想マシン基盤(WorkSpace)のみとなります。

ユースケース

Amazon WorkSpaces Coreのユースケースとしては「既存の他社VDIソフトウェアを使いつつ、インフラをAWSのマネージドなものにしたい」場合となります。

VDIソフトウェアを変えないことによるインフラ移行の容易さやユーザー教育コストの削減などが主なメリットとなります。
オンプレ環境からの移行であればAWSインフラを使うことによる伸縮性、WorkSpacesの基盤を使うことによるデプロイ容易性もメリットです。

ちなみにAmazon WorkSpacesの自体の利用費も少し安くなりますが、これは他社VDIソフトウェアのライセンス費を見越した価格設定のためトータルするとそこまでコストメリットは無いはずです。

サービスの状態

Amazon WorkSpaces Coreが本日時点でプレビューなのかGAしてるのか正直よくわからなかったのですが、VMware Horizon 8 build 2209以降のバージョンであれば実際に動作させることができる点とVMware側のリリースノートを見る限り

Horizon 8 VDI use cases are now supported on Amazon WorkSpaces.

とあるので一応GAしている雰囲気です。

とはいえまだサービスが発表されてから間もない状況ですので、導入を検討する際は事前にAWSに問い合わせておくことをお勧めします。

基本構成

現時点でのAmazon WorkSpaces Coreで想定しているインフラ構成としては

  1. 他社VDIのコントロールプレーンをVCPに配置 + Amazon WorkSpaces Coreで仮想マシンを提供
  2. 他社VDIのコントロールプレーンはオンプレに配置しAWSと閉域接続 + Amazon WorkSpaces Coreで仮想マシンを提供

の2パターンの模様です。

1. 全てをAWS上に配置するパターン

最初のパターンの概要はこんな感じです。

(https://pages.awscloud.com/rs/112-TZM-766/images/TechDeepDiveWorkSpacesInnovationDay.pdf より引用)

利用者のVPC環境に他社VDIのコントロールプレーン(Gateway, Control Plane, DB)を配置、認証にAWS Managed Microsoft ADを使いつつAmazon WorkSpaces Coreを利用する形になります。
VMware Horizonに当てはめると

  • Gateway = Unified Access Gateway
  • Controle Plane = Connection Server
  • DB = イベントデータベース

となります。
また、現時点で具体的な実装は無いですがコントロールプレーンをパートナーのクラウドサービスにする構成も検討している様です。

(https://pages.awscloud.com/rs/112-TZM-766/images/TechDeepDiveWorkSpacesInnovationDay.pdf より引用)

2. コントロールプレーンをオンプレに配置するパターン

コントロールプレーンをオンプレに配置するパターンはこんな感じです。

(https://aws.amazon.com/jp/blogs/desktop-and-application-streaming/extending-vmware-horizon-to-amazon-workspaces/ より引用)

オンプレ環境とVPCをDirect ConnectやSite to Site VPNで接続して使う形になっています。
VMware Horizonの場合

One of the requirements is to insure you have 120-ms or less latency from on-premises Connection Servers to Amazon WorkSpaces desktops over a private connection.

とConnection Serverから仮想マシン(WorkSpaceインスタンス。上図ではPrivate Subnetに生えてるENIが該当)に対するレイテンシーが120ミリ秒以下である必要がとのことで安定したネットワーク環境が必須となっています。

補足 : 複合パターン

最後に複合的なパターンとしてVMware Horizonにおいてオンプレ環境PodとAWS上でAmazon WorkSpaces Coreを使ったPodを併用することも可能な様です。
(VMware的には通常のCloud Pod Architectureっぽいです。単純にPodの一つがAWSにあるというだけのイメージ)

(https://pages.awscloud.com/rs/112-TZM-766/images/TechDeepDiveWorkSpacesInnovationDay.pdf より引用)

終わりに

以上となります。

現時点の情報でAmazon WorkSpaces Coreの全体像がだいぶクリアになったと思います。
具体的な設定方法やAPIの仕様といった部分でまだまだ見えない所はありますが、細かい点はこれから情報が増えていくことでしょう。

引き続き来年も情報を追っていきたいと思います。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.